CRM Development – As easy as making a cup of tea?

Last weekend I attended the Dynamics 365 Saturday Summer Bootcamp in London; this was a great event full of opportunities to network, engage and learn, and I am very grateful to the organisers for putting on the event.  Whilst at the event I was speaking to someone who told me that he was currently working as a business analyst but was considering training to become a CRM Functional Consultant and it got me thinking about the importance of business analysis skills to me in my role.

Always ask “Why?”

Before I became a CRM Consultant I studied Law at university, and I’ve trained as an ISO9001 internal auditor in previous job roles.  This background has provided me with a strong ability to analyse and understand business process, though my biggest asset is probably my incessant asking “Why?”.

I’ve spent countless hours developing solutions for CRM that then go unused by the business after deployment, and I could’ve saved so much of this time if I’d just asked “Why” a bit more.

• Why do you need this solution?
• Why are you recording this information?
• Why does the process work like this?
• Why can’t we use existing functionality?

The key thing is to make sure you have enough detail so that you have a full understanding of the requirements before you even commence development.  Think of it as a modern version of “measure twice, cut once”.

Creating Process Flowcharts

I have a logical mind, so I like to document all of my processes in flowcharts before I get underway with development.  I find a flowchart helps me to keep my thoughts in check and guides me in my development of system updates.  A good flowchart should be comprehensive but clear; it should provide you with all of the steps in the process and should have a clear, logical path to follow.  Anyone who has used Visio in the past can probably attest to the simplicity of creating flowcharts, though I think there is a bit of an art to making a good flowchart.

In order to demonstrate the level of detail I look for in a flowchart, I thought it would be useful to think of it in terms of a process that everyone can understand – making a cup of tea!

How to make a cup of tea

I know what you’re thinking – everyone knows how to make a cup of tea, it’s a waste of time to document the process.  Fortunately, this is a really simple process to document:

So that’s us done right?  If only it were that easy…

I’ve experienced plenty of processes like the above, they are a weak attempt at documenting how a process works, and miss out quite a lot of the detail.  For a start, if you boil a kettle without adding water to it, you’re gonna have a bad time.  I’ve yet to make a cup of tea for a group of people without there being variables involved, some people want milk in their tea, and some people want sugar.  Some want both, some want neither.  So let’s start over and create a process that includes these variables:

Ah, that’s better!

This is a much more detailed process, and accounts for the variables at different steps.  A little bit of extra thought, and asking a few more questions about the process has helped us to capture a lot more information and ensure the process accurately reflects the actual work being completed.

Unfortunately, I think this is still too simple.  There are lots of different types of tea, and they have different preparation processes.  In most businesses, their processes may have multiple divergent paths based on decisions taken at different parts of the process, and this can have a massive knock-on effect to your development if you don’t account for it at the planning stage.  I’ve lost so many hours to poor planning and a lack of understanding of the needs of the business when I’ve been creating my solutions.  Trying to unpick a solution after implementation can be time-consuming, painful and frustrating.

A comprehensive tea making flowchart might look like the below:

This process accounts for multiple variables, divergent paths, and includes a lot of detail that would help me understand what I need to do to make sure my system can account for all of the steps.  It is possible to make this even more detailed if you wish, though you also have to know where to draw the line and not to add complexity for no additional benefit

Conclusions

As I’ve hopefully demonstrated above, it’s really easy to make a simple process, but there are risks involved in basing your system development on poor information.  Spending the time at the start to ensure that you fully understand the needs of the business and the process problem you’re creating a solution for will ensure that your development time will not be wasted.

At the very least, after reading this I hope you know how to make a cup of tea!